Grupo 4 - Borroo

En esta página se encuentra el feedback recogido por el equipo del grupo 4 durante las sesiones de clase. Con secciones para cada semana, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana. Además, se incluye una sección para cada grupo con el feedback proporcionado por el grupo 4.

Feedback Semana 2

Feedback relacionado con la presentación

• Mantuvimos un buen ritmo de presentación.
• Los márgenes de la presentación deben adaptarse al proyector (4/3).
• Número demasiado elevado de diapositivas, es mejor mostrar menos diapositivas, aunque digas lo mismo.
• Debemos asegurarnos completamente de que la letra sea legible desde el final de la clase.
• Hemos usado un buen contraste de colores.
• No podemos poner todos los competidores en las transparencias, los más importantes y los que se puedan asimilar.

Feedback relacionado con el desarrollo del proyecto

Idea de negocio

• Segmentar. ¿Qué es esto?
  • Tenemos que dividir el mercado en grupos específicos de clientes que comparten características. NO ES quitarle, por ejemplo, categorías de productos que vendemos, sino enfocarnos más en hacia QUIÉN va el producto, no una característica PROPIA del producto.
  • Podéis encontrar distintas segmentaciones del mercado, por ejemplo: Demográfica, Psicográfica, Geográfica o por comportamiento.

Tipo de negocio

• Explicar el tipo de proyecto de una forma más clara y concisa. De momento lo hemos reescrito de la siguiente forma:

  Nuestro proyecto crea una plataforma donde las personas pueden alquilar y ofrecer en alquiler todo tipo de objetos, sin necesidad de comprarlos o venderlos. Aunque ya existen servicios específicos para alquilar viviendas, coches o cámaras, no hay una plataforma única que reúna todas las categorías en un solo lugar. (aquí estaría mencionando de manera indirecta el improved market)

  Nuestra idea es facilitar este proceso, permitiendo que cualquier persona encuentre (aquí estaría mencionando lo de matchmaking) y ofrezca productos como herramientas, electrodomésticos, ropa, equipos deportivos o tecnología en un solo sitio web o app. Así, quienes necesitan algo por un tiempo pueden acceder a ello fácilmente, y quienes tienen objetos sin uso pueden ganar dinero con ellos.

  Este modelo no solo hace que el acceso a productos sea más económico y flexible, sino que también ayuda a reducir el desperdicio y fomenta un consumo más inteligente y sostenible.

Análisis de competidores preliminar

• 5 competidores es poco, más exhaustivo. Mínimo añadirle 20 competidores más.
• Hay que dejar claro qué tenemos nosotros que no tenga la competencia, pero los cambios que tengamos nosotros deben ser sustanciales, por ejemplo: una integración de un chat no lo es.
• Tiene que ser un análisis excelente. Es de lo más importante.

Diferencia entre cliente y usuario

• De este punto tenemos que enfocarnos en usuarios pilotos y clientes potenciales.

Análisis de coste preliminar

• Realizar el TCO. ¿Cómo?
• Definir el alcance, es lo primordial de la aplicación.
• Existen costes directos e indirectos y costes imprevistos (análisis de riesgos, planes de contingencia).
• Rentabilidad y sostenibilidad.
• Revisar fórmula para calcular TCO.
• Realizar los planes de contingencia más desarrollados.

Matriz DAFO

• Es importante entender la diferencia entre una descripción de la matriz y su análisis.
  • Describir: Es simplemente listar debilidades, amenazas, fortalezas y oportunidades.
  • Analizar: Conectar los puntos para tomar decisiones estratégicas de negocio. Por ejemplo, las fortalezas MITIGAN las amenazas.

MVP

• Definir bien el alcance de la aplicación.
• Mockups.
• Modelo de distribución de software: ¿Cómo se va a plantear este producto? ¿PaaS, P2P, Freemium? Explicarlo y desarrollarlo, se puede enlazar con el tipo de negocio.
• Casos de uso CORE: Son los puntos CLAVE por los que los clientes estarían dispuestos a financiarnos.

Financiación

• Realizarla.

Descripción del equipo

• Realizarla.

IA

• Para la entrega añadir qué tipo de prompts hemos usado si son interesantes.

Usuarios pilotos

• Hacer alguna encuesta para saber un poco el tamaño del mercado y también analizar a los posibles usuarios interesados. Qué personas estarían interesadas en usar la aplicación.
• Definir los casos de uso, ¿qué funcionalidades estarían dispuestos a pagar nuestros clientes?
• Tiene que haber usuarios dispuestos a pagar por la aplicación para que salga adelante.
• Aproximadamente entre 20 y 30 usuarios pilotos.

Tareas a realizar para la siguiente semana

1. Corregir todo lo que tengamos mal en base al feedback anterior.
2. Hacer mockups funcionales, aunque no estén bonitos todavía.
3. Tener todos los Customer Agreements y todos los documentos firmados.
4. Empezar planes de gestión priorizando el de riesgo.

Feedback Semana 3

Feedback relacionado con la presentación

• La letra sigue sin verse desde la posición de los profesores.
• Hemos puesto demasiada letra con lo que la audiencia pierde atención.
• La imagen corporativa de la presentación está bien.
• Presentarse al comienzo.
• Hay que destacar lo positivo de nuestro trabajo frente a lo negativo.
• Competidores debe ir antes que los mockups.
• Algo que llame la atención al público al principio para captar su atención.

Feedback relacionado con el desarrollo del proyecto

Análisis de competidores preliminar

• Que quede muy claro lo nuestro frente a los demás, no de uno en uno, más en general.
• Cómo hemos encontrado esos competidores.
• Competidores directos.

Diferencia entre cliente y usuario

• Definir qué tipo de tiendas pueden usar nuestra aplicación.

Análisis de coste preliminar

• Pequeño desglose, que se pueda asimilar y que se vea de forma clara.
• Buscar en qué nos diferenciamos con Rentuki. ¿Qué pasa si consiguen un gran público? Sería una aplicación exactamente igual a la nuestra.
• 100 euros en marketing es demasiado poco.
• Sería interesante meter estimaciones de usuario.

Matriz DAFO

• El DAFO ya no era para esta semana.
• En nuestra presentación, más que un DAFO eran los riesgos. No encajan las debilidades con las oportunidades.

MVP

• Definir el tiempo de alquiler.

Financiación

• Calcular el tiempo en que empezaremos a sacar rentabilidad con los gastos estimados en el TCO. Habría que ver la financiación si va mediante planes, acuerdos con empresas u otra forma.

Descripción del equipo

• No aparecen los nombres de las personas que participan en el equipo. También tiene que aparecer una foto de cada miembro del equipo.

Documentación

• Actualizar Customer Agreement (CA): especificar que nos comprometemos a las tareas de esa semana y que habrá un responsable de esa tarea. Encargado de calidad visual por ejemplo de las presentaciones. Decir también en la presentación si ha habido alguien que no haya cumplido algún punto del CA. Generar versiones distintas del CA, tiene que estar actualizándose cada semana. Subsanar más los incumplimientos del CA sin tener que echar del grupo. Una opción de penalización es apoyarnos en la nota que le damos a los compañeros. Tiene que haber gente que sea responsable de supervisar, esto debe definirse en el CA.

Usuarios pilotos

• Poner una ratio de respuestas respecto a los mensajes enviados de las encuestas si tenemos.
• Hacer encuestas y analizarlas, llamar y hablar con posibles usuarios pilotos.
• Esas encuestas deben tener un grado de detalle sobre el que sacar conclusiones a mencionar, y de ahí concretar el valor diferencial de nuestra aplicación.
• Realizar análisis exhaustivo de usuarios pilotos para sacar funcionalidades que nos diferencien, rentabilidad de la aplicación, interfaz de usuario...
• Grado de innovación tecnológica.

Mockups

• Mockups de casos de uso core. Resaltar los casos de uso core. (login no es un caso de uso core).
• No se podían leer. Hacer zoom de las distintas partes.

Riesgos

• Poner en la presentación los riesgos más importantes.
• Añadir riesgos (yo pondría aspectos claves del análisis de riesgos).

Tareas que realizar durante esta semana:

1. Corregir todo lo que tengamos mal en base al feedback.
2. Actualizaciones del agreement, responsables de tareas y/o partes del proyecto, debe estar reflejado en el Commitment Agreement.
3. Si no se cumple algún punto del agreement, decir la razón (anexo o versionado). Poner penalizaciones antes de echar del grupo para poder reencaminar la situación. Como en cada entregable nos valoramos los unos a los otros, ahí podemos reflejar esas penalizaciones. Responsables de revisar las cosas.
4. Qué es un riesgo – evento que puede causar pérdidas económicas. Análisis de riesgos más exhaustivos, poner los más importantes (hay que priorizar), decir en qué consiste, probabilidad, consecuencias y acciones para mitigarlo (o mitigar esas consecuencias).
5. TCO se expresa por meses, no por años. No incluir el IVA. Costes en TOTAL (costes en los que recae la empresa, distintos de salarios brutos y netos). Tener en cuenta lo que le cuesta a LA EMPRESA. Tener en cuenta el coste de Github para desarrollo.
6. Hora básica de servicio (precio).
7. TCO ni muy genérico ni muy específico, que se pueda leer.
8. Idea de negocio, elevator pitch (50 palabras) - Inicio efectivo, captar la atención del público.
9. Tipo de negocio.
10. Análisis de competidores.
11. Análisis preliminar de costes: TCO, coste personal, de amortización del proyecto, infraestructura y licencias (app engine, etc.) y costes indirectos, y mantenimiento.
12. Gestión de usuarios pilotos (hay una píldora teórica de usuarios piloto).
13. MVP, mockups, más específicos con objetivos del SPRINT 1 sobre los casos de uso a implementar en ese sprint. TODOS LOS CASOS DE USO CORE.
14. Innovación, stack tecnológico.
15. Plan de gestión de riesgos (píldora teórica).
16. Refinar el equipo, buena imagen, que aparezcan los miembros, imagen corporativa (todos similares, en el mismo sitio, misma vestimenta...).
17. Commitment agreement.
18. Desarrollo – plan de gestión de la calidad del desarrollo – modelo de análisis, como vamos a intentar medir y solucionar ese problema en el proyecto.
19. Modelo de rendimiento del proyecto. Cómo va cada persona cada semana. CUANTITATIVO. (6h, 8h, 10h).
20. ALM – herramientas tecnológicas obligatorias (github, github actions – CI/CD, github project para gestión de tareas – luego se evalúa la monitorización de tareas de equipo (gráficos y tal).
21. TIME TRACKING (clockify).
22. Gestión del código (política de etiquetado, para los entregables, definir cómo vamos a etiquetar cada cosa y qué política vamos a seguir para el versionado del código).
23. Se despliega cada parte por separado. Nada de sustituir el sprint 1 por el 2 ni nada por el estilo. Platafor

Feedback Semana 4

Feedback de otros grupos

• Tener una tabla de competidores clara, que te permita entenderla sin escuchar la presentación.
• Asignar roles en la presentación, no solo poner fotografías.
• Innovar en el inicio de la presentación.
• Traer practicada la presentación.
• Tener los usuarios piloto bien difinidos, X usuarios son empresas, Y son particulares.
• Enseñar conclusiones del uso de la IA, no la metodología que se va a seguir.
• Revisar el video propuesto para la vocalización.
• Intentar buscar mas usuarios piloto.
• Usar k o m para números grandes.
• Explicar como se gestionara el trato con los usuarios piloto.
• Revisar fotografías para que no esten distorsionadas.
• Numerar las diapositivas para facilitar la referenciación.
• Tener una landing page.
• Buscar usuarios piloto acorde a la tematica de la aplicación.

Feedback relacionado con la presentación

• Empleamos buen tono de voz.
• Usamos ejemplos cotidianos que ayudan a que se entienda nuestra idea.
• Presentación fluida y con una buena gama de colores.
• Presentarse al comienzo.
• Inicio soso, necesitamos hacer algo tipo teatro.
• La landing page debe ir al principio de la presentación.

Feedback relacionado con el desarrollo del proyecto

• Es bueno tener el máximo de usuarios pilotos posibles.
• Debemos ajustar mejor el tema de pagos semanales, únicos y anuales.
• Aclarar si anuncio de alquiler es core.

Tareas que realizar durante esta semana:

Reloj de avance del proyecto

Cuánto tiempo hemos invertido de lo esperado hasta final de curso. Cuánto tiempo llevamos y cuánto nos quedaría (barrita de progreso).

Planificación (15/20%)

Reestimación para el S1 y objetivos finales para el S1. Reestimación para el S2 y S3 en caso de que se vea afectado.

Gestión de usuarios piloto (10% ir al grano)

Agenda para trabajar con ellos. Cuándo vamos a contactar. Cuántos días les damos para responder. Cuándo les entregamos el software. Cómo abordar el feedback que nos den. Que quede claro el compromiso, mejor quedar con el usuario para el feedback.

Plan de gestión para el sprint siguiente

Uso de la IA

Resumen de cómo la hemos usado durante el S1.

Presentación más técnica

Rendimiento. Solución de problemas.

Ensayar despliegue a la mitad del sprint

Si no desplegamos en la presentación, SUSPENSO.

Feedback Semana 5

Feedback de otros grupos

• Hacer un buscador en la base de conocimientos comun.
• Tener todos la documentacion en md.
• Presentarse antes de exponer.
• El registro y el inicio de sesión no son relevantes para la demo.
• Demo no visible desde el final de la clase.
• Usar métricas optimas para la productividad, el número de commits no es una buena referencia.
• Tener una evolución de los problemas, desde que se detectan hasta que se resuelven.
• Evitar hablar mucho sin apoyo visual.
• Killer opener relacionado con la temática de la aplicación.
• La presentación debe ser autocontenida.
• Evitar tener demasiadas diapositivas.
• Evitar ser informales en videos publicitarios y que esten enfocados al público de la aplicación, no a los asistentes de la clase.
• Evitar fuentes extrañas que puedan dificultar la lectura de la presentación.
• Usar k o m, para los miles.
• Las diapositivas no es un apoyo, es un refuerzo del speech.
• Si el chatgpt te ahora 4 horas, invierte esas 4 horas en otra cosa.
• Dar mas importancia al "in review" que al "done".
• Ser responsables con el burnup, tener bien definidas las task antes de empezar el sprint.

Feedback relacionado con la presentación

• Alumnos y profesores coincidieron en que la presentación tenía demasiado contenido.
• De la mano del anterior punto, intentar hacer una presentacion mas tranquila y sin correr.
• Antes de mostrar la demo de la aplicación, contar que se va a hacer para que al oyente no le pille de imprevisto.
• Buscar una mascota que no pueda ocasionar probemas a nivel legal por derechos de autor/copyright (Doraemon).
• Buscar la manera que se vea bien la demo, zoom, recortes...
• Ser muy claros a la hora de decir que nos diferencia de los demas competidores.
• Añadir el plan de contingencia a la presentación.
• Redondear los precios(usar m o k).
• Intentar actuar de manera mas tranquila ante adversidades en la presentación(final abrupto de la demo ya que estaba grabado con sonido).
• Mejorar la apariencia de la diapositiva del modelo cuantitativo.
• En la diapositiva del modelo cuantitativo definir que tipo de calidad es.
• Reestructurar la diapositiva de problemas y añadir el número de la página.
• Respecto a los problemas, ¿que medidas se van a tomar?, ¿estan solucionadas?
• La retrospectiva debe tener un gran peso en la presentación.
• Hay que enlazar, si procede, los problemas que surjan con los riesgos previstos.
• Añadir titulo a la diapositiva 20.
• Poner el porcentaje de alucinaciones de la ia

Feedback relacionado con el desarrollo del proyecto

• Parametros para el modelo cuantitativo.
• ¿Teneis alguna forma de saber que el coordinador coordina correctamente?
• Reestructurar las reuniones para evitar tiempo vacio en clockify

Tareas que realizar durante esta semana:

• Hay que crear parametros, de manera que la gente pueda saber que tiene que hacer para tener un buen rendimiento en el modelo cuantitativo.
• Establecer un criterio base para que los coordinadores sigan el mismo criterio de manera consensuada.
• Continuar con las tareas que quedan del sprint.
• Correguir el feedback realicionado con la presentación.
• Seguir las indicaciones para la entraga siguiente:
  • Killer opener 1 min
  • Elevator pitch 30 seg
  • Analisis de competidores
  • Analisis de costes(TCO) capex y opex
  • Seguimiento de como vamos esperado vs realidad
  • Estimacion a corto(4-6 meses) y medio(1-2 años) plazo de los gastos e ingresos(justificados, numero de clientes) pesimista optimista y real
  • Equipo y roles max 2 mins
  • Demo VISIBLE 15% d presentacion
  • Retrospectiva
    • Analisis del rendimiiento del equipo
    • Medir calidad de software
    • Problemas y sus estados
    • Lecciones aprendidas
    • Medicion si esta funcionando el mecanismo de solucion del problema
    • Reloj del avance del proyecto(respecto al final de curso)
  • Usuarios pilotos cuantos, roles, como te comunicas con ellos, como gestionas el trabajo con ellos, y como lo pensais para el sprint 2
  • Replanificacion
  • Reporte del uso de IA y que seamos criticos
  • Landing page

Feedback Semana 6

Feedback de otros grupos

• Elevator pitch mas lento, debe ser un mensaje con el que se quede el espectador.
• Intentar no ser tan pesimista en los costes.
• Hay que tener cuidado con donde deplegamos la aplicación puede ser que se acaben los creditos y no este desplegada en una evaluación.
• Intentar buscar soluciones mejores que hacer un grupo grande con todos los miembros, ya que eso lo identifico otro grupo como un problema.
• Demos con datos realista, tener profesionalidad.
• Desglosar bien el Opex y el Capex.
• Cuidado con las traducciones literales.

Feedback relacionado con la presentación

• Buscar una mejor razón por la que Don Ramón usaría la aplicación, ya que al no poder usar a Doraemon como mascota, hay que crear un buen Storytelling que tenga sentido.
• Mostrar la vision anual del Opex respecto a la situación actual.
• Falta la solución a los problemas que nos surgen.
• Reestructurar la demo y utilizar algo que diferencie el rol de la persona que usa la aplicación en la demo(el que pone en alquiler, el que alquila).
• Destacar de otro color los cambios de que se hagan en el sprint.

Feedback relacionado con el desarrollo del proyecto

• Como avanzara la linea roja de costes, ¿que haremos para frenar esa subida tan brusca?

Tareas que realizar durante esta semana:

• Comenzar el sprint 2, y tener en cuenta el feedback de esta semana.

Feedback Semana 7

Feedback de otros grupos

• Añadir grafica de costes.
• Buscar mayor apoyo visual en la presentación.
• Añadir email de contacto en la última diapositiva.
• Pulir las demos para que se escuchen y se vean bien.
• Mostrar que han hecho esas personas que iban cortas de horas para ponerse al nivel de las demas.
• Buscar mediciones para ver como se van solucionando los problemas.
• No estar demasiado tiempo en los competidores.
• La refactorizacion no es un cambio.
• Usar metricas de rendimiento.
• Buscar sistemas de recompensas gratuitos.
• Mostrar la evolucion de los problemas abiertos.
• Tiene que haber algoq que respalde el decir que se ha mejorado.
• Inicio demasiado largo.
• Decir cuanto suponen los porcentajes, el oyente no tiene o no deberia tener una calculadora en la mano.
• Cuidado con que falten apartados de en la presentación.
• Usar un código de colores que no de posibilidad a confusion, verde bueno, rojo malo.
• Intentar que la presentación fluya, que no haya secciones diferentes unas de otras.
• A estas alturas de la carrera sorprende el NO uso de github project en una etapa tan avanzada del proyecto.

Feedback relacionado con la presentación

• Usar k€ que es aceptado por la RAE
• ¿Es realista la gráfica de amortización? Estimar cantidad de usuarios que usan la aplicación en distintos puntos para ver si es posible que ocurra o no.
• Story board simple.
• Dejar mas claro quien esta usando la app en la demo.
• ¿La nota de los estudiantes es real?¿Se esta usando la fórmula?
• Diapositiva sobre la IA muy larga y poco currada.
• Repensar todas las diapositivas, ¿son especificas de nuestro proyecto? Evitar poner cosas generales.

Feedback relacionado con el desarrollo del proyecto

• Los usuarios piloto deberian estar YA probando la aplicación.
• Focalizar el esfuerzo en lo que nos diferencia de los demas, pedir alquileres deberia haberse implementado antes.

Tareas que realizar durante esta semana:

• Plantila para el customer agreement
• Calendario comun para las reuniones
• Recomiendan tener un change log para tener un seguimiento de en que se invierte mas tiempo
• Killer opener
• Elevator pitch
• Storyboard de un target de la app(no de inversion)
• Customer agreement terminos y condiciones pricing sla
• TCO capex opex, estimacion pesimista optimista
• Equipo, roles
• CA status, habeis cumplido el CA todos? En que medida?
• Demo
• Retrospective

  • Matriz de rendimiento y esfuerzo

    • 1 cuadrante mucho esfuerzo mucho rendimiento
    • 2 cuadrante mucho esfuerzo poco rendimiento
    • 3 cuadrante poco esfuerzo mucho rendimiento
    • 4 cuadrante poco esfuerzo poco rendimiento

  • Problemas SOLUCION como esta funcionando esta solucion

  • Lecciones aprendidas

  • Resultado de analisis de software

  • Reloj avance del proyecto

  • Gestion de usuarios piloto considerando la pildora teorica

  • Planificacion y replanificacion

  • Aspectos de Seguridad, cuentas de correo validas, tarjetas de credito realistas, dni

  • Apis que repercutan en la opex?

  • Uso de la IA, ha habido una mejora del uso? Somos mas eficientes? Al ucinaciones

  • EVITAR COSAS GENERICAS, COSAS ESPECIFICAS NO TRIVIALES DE NUESTRA APLICACIÓN

  • Landing page y correo

Feedback Semana 8

Feedback de otros grupos

• Enfocar mejor el killer opener, para remarcar el problema que soluciona la aplicación.
• Tranquilidad al presentar, no se llegan a escuchar cosas de la presentación.
• Zoom a la demo, no se ve bien al fondo.
• Dejar claro como se evalua el rendimiento.
• Si se hace un storyboard para inversores que se enfoque a ellos.
• Ensayar la presentación para evitar falta de tiempo para comprar cosas.
• Killer opener demasiado dramático.
• Unificar la tabla de costes con el número de usuarios previstos en cada hito.
• ¿Qué beneficios tienen los trabajadores de la semana?
• Dar mucha importancia a la información que se sca de los usuarios piloto.
• No son 10 horas mínimas, son 10 horas exigidas.
• Diferenciar la demo del anuncio.
• Análisis de costes, puede cambiar dependiendo del feedback de los usuarios piloto.

Feedback relacionado con la presentación

• Cortar registros y formularios en la demo.
• Buen inicio efectivo.
• Falta de elevator pitch, buscar un eslogan o algo.
• Animar la gráfica de costes para que siga al discurso.
• Agilizar la demo, quitar comprobaciones inútiles.
• Agregar cosas que tienen los competidores.
• Añadir cantidad del feedback, no solo el porcentaje

Feedback relacionado con el desarrollo del proyecto

• Añadir muchos objetos a la aplicación.
• Analizar el movimiento que hay en la aplicación.
• Añadir la fianza lo antes posible

Tareas que realizar durante esta semana:

• Killer opener
• Elevator pitch
• Anuncios en video de un target de la app(no de inversion)
• Customer agreement terminos y condiciones pricing sla
• TCO capex opex, estimacion pesimista optimista
• Equipo, roles
• CA status, habeis cumplido el CA todos? En que medida?
• Demo
• Garantias de seguridad
• Retrospective
  • Problemas SOLUCION como esta funcionando esta solucion
  • Lecciones aprendidas
  • Resultado de analisis de software
  • Reloj avance del proyecto
  • Gestion de usuarios piloto considerando la pildora teorica
  • Planificacion y replanificacion
  • Aspectos de Seguridad, cuentas de correo validas, tarjetas de credito realistas, dni
  • Planificacion para el S3
  • Uso de la IA, ha habido una mejora del uso? Somos mas eficientes? Al ucinaciones
  • EVITAR COSAS GENERICAS, COSAS ESPECIFICAS NO TRIVIALES DE NUESTRA APLICACIÓN
  • Landing page y correo

Feedback Semana 9

Feedback de otros grupos

• Esta guay que los killer opener de EventBride sigan una historia.
• Musica muy alta en el anuncio, el anuncio de inversores, no llega a ser tanto para inversores.
• No alargar tanto el Customer agreement o el SLA para que de tiempo al final de todo.
• Mostrar el porcentaje de las bodas que pretenden abarcar, para ver como de realista es.
• Explicar lo que ocurren en la demo.
• Mostrar la evolucion de los problemas.
• Cuidado con añadir demasiadas funcionalidades en el PPL que esta enfocado al marketing.
• Añadir que usuarios estan usando la aplicación en la demo para que sea mas fácil distinguir quien la usa.
• La tabla de costes que muestre el número de usuarios previstos en cada hito.
• Demo con zoom.
• Evitar anuncios raros que hacen referencias a temas sensibles(hitler).
• No hay testing.
• Ser más concretos en las medidas que se toman para ciertos problemas.
• Evitar usar tecnicismos.
• Especificad que feedback han dado los usuarios piloto y en que ha repercutido.
• Cuidado con el copyright.
• La trazabilidad en menos importante que el objetivo y el periodo.

Feedback relacionado con la presentación

• Evitar muletillas.
• Falta un eslogan al final del killer opener.
• Ha faltado la mejora de UX en la demo.
• La falta de confianza se arregla con un seguro o una fianza.
• Categorizar el feedback de los usuarios pilotos.

Feedback relacionado con el desarrollo del proyecto

• Intencionalmente en blanco.

Tareas que realizar durante esta semana:

• Ver las píldoras teóricas
• Killer opener y elevator pitch
• Competidores
• Anuncio diferente(inversores o clientes)
• Customer agreement no se pone
• Tareas de marketing preeliminares, atraccion inical de clientes
• Añadir roles para el marketing
• Costes añadir roles nuevos y los gastos de marketing
• Equipo refinado
• DEMO
• Retrospectiva S3 plan de pruebas
• Reloj de avance
• Plan gestion de usuarios pilotos
• Planificacion de cara al PPL
• IA
• Landing page

Feedback Semana 10

Feedback de otros grupos

• Bien cambiadas las espectativas para llegar al objetivo
• Evitar usar cosas como niño gordo o cosas de ese estilo
• Evitar anuncios demasiado largos
• Matriz de esfuerzo individualizadas aunque sean anonimas
• Vocalizar en los videos
• Usar datos realistas en la demo
• Intentar que la demo siga una historia, un recorrido
• En el anuncio de inversores, usar un lenguaje mas apropiado al inversor
• Cuidado con la informalidad
• Poner números, no porcentajes para no tener que hacer calculos

Feedback relacionado con la presentación

• El trabajo da buenas sensaciones
• Buen trabajo eliminando la muletilla "seguidamente"
• Buscar la motivacion para que tengas la necesidad de alquilar y no vender
• Mostrar estadisticas en el anuncio de inversores, intentar mostrar estadísticas, estudios, etc
• Bien explicado el equipo
• Recordar decir lo que se va a ver en la demo
• Mostrar como ha decrementado por ejemplo las alucinaciones con una flechita para abajo o algo asi

Feedback relacionado con el desarrollo del proyecto

• Hacer merge de ramas incorrectas es muy grave
• Testing continuos para que ese merge no vuelvan a ocurrir

Tareas que realizar durante esta semana:

• 2 presentaciones
• Preparacion para el ppl
  • De que va el proyecto
  • Que hace exactamente(demo)
  • Hay competencia
  • Quien hay detrás(equipo)
  • Puede ser rentable(Planes de precios)
  • Curvas de costes
  • Anuncio de inversores(anuncio de inversores)
  • Landing page
• Campaña de marketing
  • Personas
  • SEO
  • Campaña de lanzamiento
  • Publicaciones en redes social
  • Community management
  • Anuncios, videos, banners

Feedback Semana 11

Feedback de otros grupos

• Cuidado con la iluminacion de la clase que puede impedir ver bien la pizarra
• Intentar no explicar demasiado algo que despues se vera en la demo
• Más detalles de marketing en la primera presentación
• Eliminar la muletilla pretende, hablar en presente, por ejemplo "hace"
• Mover el anuncio de inversores a la primera presentacion
• Objetivos de la campaña de marketing
• No poner la demo al final
• No se ha seguido el hilo propuesto por los profesores
• Unificar nombres
• Evitar tecnicismos

Feedback relacionado con la presentación

• El anuncio inicial se puede reducir
• Evitar el uso de la muletilla "pequeña", pequeña demo, pequeñas funcionalidades
• Demo corta y rapida, que se vea bien el funcionamiento de la app
• Decir cuantos miembros somos antes de enseñarlos
• Aligerar los planes de inversion, son muy largos
• Las personas, dividirlas en persona que solo alquila, persona que solo pone en alquiler
• Tratar de convencer con el anuncio de inversores
• Planificación de marketing con fechas y tal
• El inicio efectivo, no es un inicio efectivo
• Alguien que no sabe de que va el proyecto no se entera hasta el final
• Hablar en futuro, por ejemplo sera rentable??
• Hablar de transacciones para el tema de comisiones
• Paquetes de inversion ha demasiados reducir a 1 o 2 y decir que estamos abiertos a otras opciones

Feedback relacionado con el desarrollo del proyecto

• Intencionalmente en blanco

Tareas que realizar durante esta semana:

• 2 presentaciones
• Preparacion para el ppl
  • De que va el proyecto
  • Que hace exactamente(demo)
  • Hay competencia
  • Quien hay detrás(equipo)
  • Puede ser rentable(Planes de precios)
  • Curvas de costes
  • Anuncio de inversores(anuncio de inversores)
  • Landing page
• Campaña de marketing
  • Personas
  • SEO
  • Campaña de lanzamiento
  • Publicaciones en redes social
  • Comunity management
  • Anuncios, videos, banners